Motivation

This PR addresses issue #1138 "Handling of operational webhooks server name" which was identified after users experienced problems configuring and troubleshooting operational webhooks in local development environments.

The current implementation of operational webhooks has two key issues:

1. The server URL provided in SVIX_OPERATIONAL_WEBHOOK_ADDRESS is not validated or sanitized before use, leading to problems when users provide URLs with trailing slashes or incorrect formats.

2. When operational webhooks fail to deliver with a 404 error, the system logs a generic "Operational webhooks are enabled but no listener set for {org_id}" message, without distinguishing between different failure scenarios (e.g., incorrect URL format, missing application, or missing endpoint).

These issues make it difficult to diagnose and resolve operational webhook configuration problems, as referenced in discussion #1125 where a user couldn't get operational webhooks working locally.

Solution

This PR implements three key improvements to the operational webhooks handling:

1. URL Validation: Added validation for the operational_webhook_address configuration value in cfg.rs that verifies:

   • The URL has a valid format
   • The URL uses http or https scheme
   • The URL includes a valid host

2. URL Sanitization: Enhanced the OperationalWebhookSenderInner::new method in operational_webhooks.rs to properly sanitize URLs by:

   • Trimming whitespace
   • Removing trailing slashes
   • Preserving the essential URL structure

3. Improved Error Handling: Expanded the error handling in send_operational_webhook to provide more detailed diagnostics:

   • Distinguishes between "no application exists" and "no endpoint configured" scenarios for 404 errors
   • Adds specific handling for BAD_REQUEST errors that often indicate URL format issues
   • Includes the actual URL in error messages to aid debugging